home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
isis
/
isis-minutes-91nov.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
8KB
|
198 lines
CURRENT_MEETING_REPORT_
Reported by Ross Callon/DEC
Minutes of the ISIS for IP Internets Working Group (ISIS)
Agenda
1. Update to ISIS MIB (Chris Gunner)
2. Update to RFC 1195 (Ross Callon)
3. ISIS-BGP Interactions (Yakov Rekhter)
Update to ISIS MIB draft
Chris Gunner presented an updated draft of ISIS MIB. The major changes
from the previous draft were:
o The number of table were reduced from the previous version - now
there are half as many tables roughly as previously.
o No restriction on Set PDU's contents in the MIB specification. An
agent, however, can impose one on the Set PDU's contents.
There was a suggestion to link the IP destination object and the IP
Forwarding Table.
Additional detail-level reviewers of the ISIS MIB would be appreciated.
It is expected that this will occur at the MIB is implemented. The
IS-IS MIB is currently an Internet Draft.
Update to RFC 1195
Ross Callon presented an updated version of RFC 1195. The changes to
RFC 1195 are listed in Section 6 of the new draft (which has been
distributed to the Working Group).
Following changes and topics were discussed:
o Reference to final International Standard of ISO 10589. This is
the biggest change to the draft. This allows several sections of
RFC 1195 to be removed as they are redundant with corrections and
improvements that have been made to ISO 10589. For example,
Annexes on encoding of sequence number packets and on
authentication are now redundant with ISO 10589.
o The spec now allows announcement of the IP Router ID over
unnumbered links. This is needed for Strict Source Routing,
network management, and for locally originated IP packets over
unnumbered links. The spec will be updated to specify that for
routers which have only unnumbered links, the router ID must be
1
announced in the LSP's as a Host Route. The spec should probably
also include a brief description of what a router ID is.
o What should be done when a router is a L1 and L2 router, doing RIP,
but L2 is not IP capable? The spec now describes this in some
detail, but some editorial clarification is needed (see the "mixed
operation" section of the update to RFC 1195).
o NSAP address for IP-only routers was discussed. There are several
ways in which these can be obtained. This is currently being
pursued in several other places for uses which include, but which
go well beyond use in IS-IS. Therefore this should be removed from
the update to RFC 1195.
o There was a discussion of how to transition two instances of IS-IS
which are operating in "Ships in the Night" mode to a single
instance of Integrated IS-IS. Ross proposed two possible transition
methods, one of which was well received and the other of which was
quickly rejected. Implementations will not be required to be able
to run two instances of IS-IS in this manner. However, if an
implementation does implement the capability of running two
versions of IS-IS in SIN mode, then the implementation must also
implement the controls needed to be able to transition from SIN
mode to integrated mode and vice versa.
o An optimization of when to leak routes from L1 to L2 was discussed
and approved. This would optionally allow selective leaking of
routes from level 1 to level 2 LSPs, in a manner which not effect
routes (except for an improvement in routes in one obscure case)
but which would reduce the amount of information in level 2 LSPs,
at the cost of slightly more work for the routers doing the route
leaking. This feature would work well even when implemented by
only some routers, and therefore can be optionally implemented and
deployed.
o There was a discussion of redundant manually configured summary
routes. It was agreed that this issue was not particularly
important, but that the spec should be complete and unambiguous.
The decision was that when redundant summary addresses are manually
configured, both are announced.
o Dino Farinacci suggested that we can use the LSP protocols
supported field to avoid creating a black hole when all routers
within an area are not the same type (all OSI, all IP, or all
Dual). Again this was a feature which will work well even when
implemented by only some routers in an area (routers which do not
implement this will interwork with those that do). This proposal
was accepted.
Ross agreed to update the spec based on this discussion, and to have
this issued as an Internet Draft when available.
2
BGP - ISIS Interaction
Yakov Rekhter presented the issues of interaction between BGP and IS-IS.
After the discussion, Sharad Sanghi of ASN (sharad@ans.net) and Atul
Bansal (bansal@wile.enet.dec.com) volunteered to write BGP-IS-IS draft.
Leakage of routes between BGP and IS-IS was discussed, and it was agreed
that this should be the same as in the OSPF-BGP case.
The relationship between BGP router IDs and IS-IS router IDs was
discussed.
Piggybacking of BGP information in IS-IS packets was discussed. In
those cases where all or most level 2 routers are border routers running
BGP, this makes sense (IS-IS solves the n-square BGP link problem, and
provides reliable multicast mechanism). However, in those cases where
very few level 2 routers are border routers, the n-square link problem
is not significant, and piggybacking requires non-border routers to
store BGP information. It was therefore agreed that whether to
piggyback BGP information on IS-IS packets or to run internal BGP will
depend upon the network environment, and therefore both possibilities
should be allowed. If a network has very few BGP speakers then I-BGP is
a good solution. If a network has lots of BGP speakers and very few
non-BGP speaking L2 routers then Piggybacking is most efficient.
Auto-configuration of I-BGP neighbors was also discussed. Auto I-BGP
configuration optimization was suggested as an efficient mechanism for
discovering I-BGP neighbors. This feature eliminates the nightmare -
manual configuration of I-BGP neighbors. This autoconfiguration can be
piggybacked on IS-IS.
Tagging is currently defined by RFC 1195. This should continue to be
available.
We also discussed how to pass BGP information between two I-BGP
neighbors when one is doing OSPF and the other is doing ISIS? This
required close cooperation with the folks working on BGP-OSPF
interactions.
Attendees
Atul Bansal bansal@wile.nac.dec.com
Robert Blokzijl K13@nikhef.nl
Daniel Blum 4108980@mcimail.com
David Bolen db3l@nis.ans.net
Ross Callon callon@bigfut.enet.dec.com
Ken Carlberg carlberg@cseic.saic.com
Dean Cheng dean@sunz.retix.com
Chi Chu chi@sparta.com
Kurt Dobbins dobbins@ctron.com
Dino Farinacci dino@cisco.com
Chris Gunner gunner@osicwg.enet.dec.com
Christine Hemrick hemrick@cisco.com
Tony Li tli@cisco.com
3
April Merrill abmerri@tycho.ncsc.mil
Dave Monachello dave@pluto.dss.com
Dennis Morris morrisd@imo-uvax.dca.mil
Yakov Rekhter yakov@watson.ibm.com
Manoel Rodrigues manoel.rodrigues@att.com
Sharad Sanghi sharad@ans.net
Harvey Shapiro shapiro@wnyose.nctsw.navy.mil
Ravi Srinivasan ravi@eng.vitalink.com
Andrew Veitch aveitch@bbn.com
Cathy Wittbrodt cjw@nersc.gov
Osmund de Souza osmund.desouza@att.com
4